I'm a bit worried that you have to resort to using scalajs-cli in scala-cli. scalajs-cli should be a last resort. It is always better to use the linker API if one can do so. Reasons include:

• scalajs-cli incurs the JVM startup time
• it cannot reuse its Linker instance, and therefore cannot work incrementally.
• it does not support all the linker configuration operations
• it is barely maintained

• scalajs-cli incurs the JVM startup time

We default to native launchers of scala-js-cli in the current state of this PR. These are built from this repository and pushed as GitHub release assets, where Scala CLI later downloads them. (We already do that kind of thing for scalafmt and metabrowse).

• it cannot reuse its Linker instance, and therefore cannot work incrementally.

Not sure we were using that from Scala CLI for now anyway. I guess we'll have to make scala-js-cli a server to use that.

• it does not support all the linker configuration operations

In the current state of this PR, we rely on this fork of scala-js-cli (while waiting for scala-js/scala-js-cli#42). I guess it's fine for us to add missing features to scala-js-cli as we add support for them in Scala CLI.

• it is barely maintained

We can basically vendor it for Scala CLI if needed (via this fork). From the Scala CLI point of view, it's basically bits of code that used to be in Scala CLI, and now live in a separate app.

@sjrd One of the motivations for that is to save the cost of processing the Scala.JS linker classes when generating Scala CLI native images. We're a bit short on memory on our CI workers, to the point that it prevents us from merging some newer developments. And the Scala.JS linker classes seem to take up quite some space in the Scala CLI native images.

Seems native image generation works much better with these changes: it takes less than 10 minutes on Linux and Windows, none of the native image jobs complains about time spent in GC, and the native-image memory logging doesn't go above ~3.5 GB 🎉